It shouldn't use kind 14 directly. It should use a new kind just for for this. We already have kind 15 for images on DMs, so orders could be 16, maybe?

Cheers @vitorpamplona ,

There's been a larger thread happening over on a fork, if you're interested in reading: https://github.com/gzuuus/nips/blob/7d59ffe1e81bb0bedd64752f34298118c6e57ce6/XX.md

I'm curious about kind 15. That's the kind used for a NIP-17 rumor that includes an image? What's the thinkin' there with using a specific kind for "message that includes an image". Are there other specific kinds for different message types? I don't see 'em on the NIP-17 spec.

PR is here for kind 15: #1537 This kind has been used by 0xchat of over a year now and we just integrated into Amethyst.

The key part is that most chat clients will never implement orders (or images). So, keeping the kinds separate helps them make sure they can ignore a message instead of just showing an empty or unreadable message to the user.

The other way to do this is to keep everything you need to run in the content and the tags are just extra information. For instance, on 2, you can do something like:

{
  "kind": 14,
  "tags": [
    ["p", "<buyer-pubkey>"],
    ["subject", "order-payment"],
    ["order", "<order-id>"],
    ["amount", "<total-amount>", "<currency>"],
    ["payment", "lightning", "<bolt11-invoice>"],
    ["payment", "bitcoin", "<btc-address>"],
    ["expiry", "<unix-timestamp>"]
  ],
  "content": "Your order <order-id> with items <item1, item2, item3> has been received. 
Your total is <amount>. Please pay lightning:<bolt11-invoice - same as in the tag> 
or send XXX BTC to <btc-address - same as in the tag> to complete the transaction. 
This offer expires in <expiry>."
}

In this case, the app doesn't need to support any of the tags to show the information to the user. And the user can pay the invoice externally if needed. The tags just help the app offer additional information.

To me, it is either kind 14 with the complete description in ".content" for humans and all tags helpful but optional to understanding the message OR a new kind if you require clients to parse the tags to make sense of the message and help the user go through the order.

The other way to do this is to keep everything you need to run in the content and the tags are just extra information. For instance, on 2, you can do something like:

{
  "kind": 14,
  "tags": [
    ["p", "<buyer-pubkey>"],
    ["subject", "order-payment"],
    ["order", "<order-id>"],
    ["amount", "<total-amount>", "<currency>"],
    ["payment", "lightning", "<bolt11-invoice>"],
    ["payment", "bitcoin", "<btc-address>"],
    ["expiry", "<unix-timestamp>"]
  ],
  "content": "Your order <order-id> with items <item1, item2, item3> has been received. 
Your total is <amount>. Please pay lightning:<bolt11-invoice - same as in the tag> 
or send XXX BTC to <btc-address - same as in the tag> to complete the transaction. 
This offer expires in <expiry>."
}

In this case, the app doesn't need to support any of the tags to show the information to the user. And the user can pay the invoice externally if needed. The tags just help the app offer additional information.

I think this would be ideal. I know several merchants who like to resolve their payments in DMs and to have quick access to the order messages they've received. Adding a new kind would lose that interop with the social clients that I think is a bit of the magic.

@calvadev I do have a bit of a potential opposition, though I'd be very open to exploring the possibility. Here's my thunkin' process:

While it can be enjoyable for the Merchants who resolve their checkout flow manually, I would think it would be ideal on-the-whole for checkout-related messages to be moved out of the inbox, and into its own UI.

Two primary pushes for that:

1. For very-popular Merchant accounts, their checkout messages would flood their inbox, making it difficult to parse through orders vs. social interactions, causing both a UX pain and the potential for missed orders. We are pretty bullish on the belief that Nostr e-commerce may spike in popularity over the next few years; if a large-volume Merchant were to have, say, hundreds of orders per day (we can dream!), this would cause their social interactions to be harder to keep track of (though, foreseeably at that stage, they might offload conversations to different channels of communication; speculative, but worth thinking about).

2. For automatic checkout settlement systems, like our WIP Conduit Commerce Coordinator (C3), we will need to parse the content string for the relevant data points. However, this would not be an issue if we can state in the NIP spec that the message must adhere to a certain structure, ie. enclosing data points in brackets and assuring they maintain a strict ordering scheme, or that the same data points must be contained also in the tags.

Pluses and minuses, of course; if we use a special kind, there's the risk that social-focused clients won't process the unique DM kind and thus will not present the checkout messages at all; however, a Merchant would have foreseeably already been using some sort of e-commerce enabled Nostr client to generate Products and track stock, and that client can determine whether it wants to display the checkout messages in the same inbox as other messages, or offload them to a separate part of the UX.

Thus, my vote would be:

1. Use a unique kind; ie. kind 16
2. Assure every necessary data point is captured in tags
3. Optionally include a message in content.

This is what the current spec does, so I suppose my vote is to keep it as-is, but choose an unused kind number.

LMK whatchyall think!

@calvadev I do have a bit of a potential opposition, though I'd be very open to exploring the possibility. Here's my thunkin' process:

While it can be enjoyable for the Merchants who resolve their checkout flow manually, I would think it would be ideal on-the-whole for checkout-related messages to be moved out of the inbox, and into its own UI.

Two primary pushes for that:

1. For very-popular Merchant accounts, their checkout messages would flood their inbox, making it difficult to parse through orders vs. social interactions, causing both a UX pain and the potential for missed orders. We are pretty bullish on the belief that Nostr e-commerce may spike in popularity over the next few years; if a large-volume Merchant were to have, say, hundreds of orders per day (we can dream!), this would cause their social interactions to be harder to keep track of (though, foreseeably at that stage, they might offload conversations to different channels of communication; speculative, but worth thinking about).

2. For automatic checkout settlement systems, like our WIP [Conduit Commerce Coordinator (C3)](https://github.com/Conduit-BTC/conduit-commerce-coordinator), we will need to parse the content string for the relevant data points. However, this would not be an issue if we can state in the NIP spec that the message _must_ adhere to a certain structure, ie. enclosing data points in brackets and assuring they maintain a strict ordering scheme, or that the same data points _must_ be contained also in the tags.

Pluses and minuses, of course; if we use a special kind, there's the risk that social-focused clients won't process the unique DM kind and thus will not present the checkout messages at all; however, a Merchant would have foreseeably already been using some sort of e-commerce enabled Nostr client to generate Products and track stock, and that client can determine whether it wants to display the checkout messages in the same inbox as other messages, or offload them to a separate part of the UX.

Thus, my vote would be:

1. Use a unique kind; ie. kind 16

2. Assure every necessary data point is captured in tags

3. Optionally include a message in content.

This is what the current spec does, so I suppose my vote is to keep it as-is, but choose an unused kind number.

LMK whatchyall think!

That's a very good point. I do like the option of having the content field in there to make it more easy to interop with at the social client level, but that could also just be handled in a normal NIP-17 DM even alongside the new event if there is such demand for the social integration and that could just be optional as well. There would probably still need to be some agreed upon structure for the message content in order to parse it properly in both cases.

@calvadev Nice. The current spec sticks all the data points into tags, with some required tags and the rest being optional / recommended, which I've had a right-fine time setting up for Products and Orders. A client could, I suppose, optionally open a kind 14 thread and send an nevent pointing to the Order event, ie. a receipt of purchase, and that thread can be used for general conversation about that, or any, Orders. Lots of potential there. We're planning on moving all Order threads off of the Inbox and into a "Receipts" tab.